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摘 要 : 随 着 互联 网 技术 的 发 展 ， 各 行 各 业 的 互联 网 化 进程 也 在 加 速 推 进 ， 笔 者 在 分 析 微 服务 架构 的 优势 和 采用 传统 单 体 架 
构 开 发 的 新 闻 制 作 系统 的 不 足 后 ， 利 用 微服 务 架 构 对 新 闻 制 作 系统 进行 了 优化 和 实现 ， 提 升 了 系统 可 扩展 性 、 灵 活性 以 及 开 


发 效率 ， 积 累 了 经 验 。 
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导语 

随 着 互联 网 技术 的 发 展 ， 各 行 各 业 的 互联 网 化 进程 也 
在 加 速 推 进 ， 传 统 的 软件 开发 理论 、 方 法 和 技术 已 不 再 适 
应 当前 大 型 、 复 杂 软 件 系统 的 开发 。 传 统 单 体 架构 有 开发 
效率 低 .代码 维护 难 .扩展 性 差 等 缺点 。 微 服务 架构 的 出 现 ， 
为 大 型 、 复 杂 软 件 系 统 带 来 了 可 扩展 性 、 灵 活性 等 多 种 优 
点 ， 但 对 微服 务 的 管理 和 运 维 提出 了 更 高 的 要 求 。 山 

本 文 首先 对 微服 务 进 行 了 介绍 ， 然 后 对 传统 软件 开 
发 模式 在 大 型 、 复 杂 软 件 系统 开发 中 应 用 现状 进行 了 分 
析 ， 随 后 阐述 了 微服 务 划 分 ， 并 利用 Spring Cloud 微服 务 
架构 对 新 闻 制 作 系统 进行 的 优化 和 实现 。 
1. 微服 务 简介 

微服 务 架构 是 一 种 面向 互联 网 应 用 服务 的 软件 开发 
架构 ， 主 要 应 用 于 互联 网 应 用 服务 的 服务 端 软件 开发 ， 
其 由 面向 服务 架构 SOA 发 展 而 来 。 微 服务 架构 提倡 将 单 
体 架 构 应 用 划分 成 一 组 小 的 服务 ， 服 务 之 间 互 相 协调 、 
互相 配合 。 品 

微服 务 架构 的 优点 有 : 服务 以 最 小 粒度 被 切 分 ， 每 
个 应 用 都 很 小 ， 边 界 清晰 ， 职 责 单一 ; 每 个 微服 务 都 可 
以 独立 开发 ， 对 开发 团队 的 技术 栈 要 求 更 低 ， 单 个 服务 
易于 开发 、 理 解 和 维护 ; 每 个 微服 务 都 可 以 独立 部 署 ， 
从 而 可 以 加 快 部 署 速度 ; 每 个 微服 务 可 以 自主 选择 开发 
技术 栈 ， 可 以 独立 更 新 ， 灵 活 扩展 。 微 服务 应 用 是 分 布 
式 系统 ， 但 提高 了 系统 开发 和 部 署 的 复杂 程度 ， 存 在 数 
据 一 致 性 、 服 务 依赖 、 服 务 监控 检查 等 问题 。 
2. 现状 分 析 

传统 的 单 体 架构 ( 即 应 用 程序 的 全 部 功能 被 一 起 打 
包 作 为 单个 单元 或 者 应 用 ) ,程序 随 着 功能 和 代码 量 的 
增加 ， 将 面临 维护 成 本 增加 ， 持 续 交 互 周期 长 ， 技 术 选 
型 成 本 高 ， 可 伸缩 性 差 等 问题 。 另 外 大 型 、 复 杂 应 用 一 
般 都 会 面临 各 种 各 样 的 业务 需求 ， 传 统 的 单 体 架 构 在 初 
期 简单 易 行 ,但 会 随 着 时 间 推 移 变 得 庞大 而 繁杂 。 由 于 
提供 了 大 量 的 业务 功能 ， 随 着 功能 的 升级 ， 整 个 研发 、 
发 布 、 定 位 问题 、 扩 展 都 会 变 得 越 来 越 困 难 。 


笔者 所 在 单位 之 前 开发 的 新 闻 制作 系统 多 为 单 体 架 


构 ， 大 型 而 复杂 ， 基 于 此 架构 后 续 进 行 敏捷 开发 和 业务 


扩展 都 较为 困难 。 由 于 部 分 模块 没有 进行 有 效 拆 分 ， 这 
些 模 块 在 系统 上 线 后 ， 在 迭代 、 部 署 和 管理 上 都 需要 花 
费 较 大 的 精力 ， 有 的 模块 甚至 连 编译 部 署 都 需要 花费 一 
个 小 时 之 久 。 微 服务 架构 相 比 传统 单 体 架构 所 具备 的 优 
势 , 更 适合 笔者 单位 对 媒体 融合 发 展 、 智 能 化 发 展 的 需求 。 
通过 微服 务 化 ， 当 业务 功能 变化 时 ， 系 统 可 以 快速 调整 
相应 的 服务 ， 完 成 开发 、 测 试 等 工作 ， 基 于 云 架构 和 平 
台式 部 署 等 能 力 , 实现 自动 化 部 署 ,快速 适应 业务 变化 。 


的 接口 调用 。 同 时 集成 Spring Cloud OpenFeign， 对 远程 
REST 调用 进行 自动 配置 和 绑 定 ， 并 使 用 断路 器 〈 Hystrix ) 
组 件 防 止 造 成 雪崩 效应 。 从 而 实现 只 对 服务 接口 类 进行 
改造 即 可 达到 改造 目的 ， 保 证 改造 最 少 ， 影 响 最 小 。 


3. 优化 设计 与 实现 


微服 务 开发 框架 迁移 
本 文中 尝试 将 笔者 单位 的 新 闻 制 作 系统 由 传统 服务 


架构 改造 成 Spring Cloud 微服 务 架 构 , 对 基础 架构 的 迁移 ， 
主要 涉及 以 下 几 个 方面 的 变更 。 


服务 发 现 方式 的 变更 : 
通过 Consul Client 向 Consul server 注册 、 发 现 、 消 费 


服务 。 


SpringCloud Http 调 用 » Http 调 用 RR SpringCloud 
Provider Consumer 


图 1 服务 发 现 方式 
接口 定义 方式 的 变更 : 
web 层 调用 下 层 服务 的 方式 ， 使 用 基于 REST 形式 


新 SampleXX 服务 定义 的 API 接口 如 下 : 


@FeignClient(value= "SampleXX "， 

fallback=ServiceClientHystrix.class) 
public interface SampleXX { 
@RequestMapping(value = “/xinhua/ 


getUserlnfoByUserName”, method = RequestMethod.GET) 
String getUserlnfoByUserName(@ResquestBody String 
jsonStr); 
} 


服务 启动 方式 的 变更 
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原 Web 层 服务 均 为 部 署 在 Tomcat 容器 ， 由 Tomcat 
启动 。 现 变更 成 Spring Boot 独立 应 用 启动 。 
3.2 服务 部 署 架 构 设计 

为 便于 未 来 进行 分 布 式 系统 部 署 和 管理 ， 在 虚拟 
化 层级 基础 上 引入 了 容 回 层 。 在 部 署 架构 设计 中 ， 需 要 
对 微服 务 依赖 组 件 进行 变更 和 新 增 ， 其 中 包括 : 新 增 应 
用 网 关 服 务 Spring Cloud Gateway, 应 用 配置 服务 Config 
Server， 服 务 注册 与 发 现 Consul Server/Client， 崭 路 监控 面 
板 Hystrix Dashboard， 分 布 式 链 路 监控 Zipkin Server。 迁 
移 后 的 逻辑 部 署 架构 如 下 图 所 示 。 
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封装 成 独立 的 微服 务 应 用 ， 每 一 个 微服 务 应 用 都 有 自己 
的 部 署 、 资 源 、 扩 展 和 监控 需求 。 
3.4 小 型 化 部 署 

在 对 微服 务 进 行 细 致 拆 分 基础 上 ， 实 现 服务 模块 化 
打包 、 模 块 化 持续 集成 、 模 块 化 部 署 。 利 用 Docker 的 技 
术 ， 实 现 基 础 应 用 及 服务 的 跨 平台 快速 部 署 和 启动 。 使 
用 Kubernetes 对 Docker 容器 进行 统一 管理 ， 实 现 高 负载 、 
高 可 用 ， 弹 性 扩展 。 

部 署 过 程 分 成 准备 阶段 和 部 署 阶段 。 准 备 阶段 实现 
按 模块 选择 的 功能 。 部 署 阶段 提供 模块 部 署 副本 数量 及 
其 他 基础 配置 功能 ， 以 及 多 域名 接 入 配置 功能 ， 并 在 配 


元 数据 服务 Cl/CD 服 务 
= 构建 自动 化 置 后 提供 一 键 部 署 。 通 过 上 述 部 署 过 程 ， 简 化 了 小 型 化 
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2 ”逻辑 架构 图 


3.3 应 用 层 微服 务 设计 

应 用 层 微 服务 按照 数据 服务 层 、 数 据 管理 层 、 基 础 
功能 组 件 层 、 业 务 服务 层 划分 为 四 个 层次 的 服务 。 每 层 
为 上 层 服务 提供 API 支持 ， 并 通过 业务 场景 层 的 整合 和 
集成 统一 为 B/S 客户 端 ，C/S 客户 端 和 移动 端 提供 服务 。 
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3 应 用 层 服务 划分 图 


数据 服务 层 : 集成 各 数据 源 的 资源 数据 。 
数据 管理 层 : 统一 的 文件 管理 、 图 片 管 理 ， 一 级 
VMS 等 基础 管理 服务 。 
基础 服务 层 : 提供 鉴 权 服务 、AI 服务 、 消 息 引 擎 、 流 
媒体 、 本 地 认证 授权 服务 、 管 理 配置 管理 服务 等 基础 服务 。 
业务 服务 层 : 提供 资源 管理 、 资 源 展示 、 内 容 处 理 、 
内 容 流程 和 规则 控制 、 内 容 发 布 等 业务 服务 。 
以 上 服务 将 不 再 作为 一 个 整体 对 外 发 布 ， 逐 个 拆 解 


4 小 型 化 部 署 总 体 流 程 


结语 

系统 建设 过 程 中 架构 设计 是 非常 重要 的 ， 需 要 平衡 
系统 的 可 用 性 、 可 扩展 性 、 可 维护 性 、 可 靠 性 、 高 性 能 
等 需求 ， 还 要 考虑 到 业务 功能 需求 ， 所 以 在 项 目 建设 初 
期 就 需要 明确 系统 建设 的 架构 设计 。 为 了 能 够 支撑 业务 
的 不 断 扩大 ， 需 求 功能 的 持续 增加 ， 笔 者 尝试 对 业务 系 
统 进行 基于 微服 务 架构 优化 设计 ， 本 文中 所 阐述 的 设计 
方案 已 经 在 实际 工作 中 进行 实施 ， 在 此 架构 上 后 续 进 行 
的 敏捷 开发 工作 能 够 快速 应 对 业务 调整 及 需求 变化 ， 提 
高 了 系统 的 适用 性 和 扩展 性 ， 笔 考 所 在 团队 将 进一步 总 
结 经 验 ， 加 强 思考 ， 继 续 探 索 ， 以 期 获得 相关 经 验 。 卓 
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